【Day - 5】最後，我決定把前兩次略過的 clarify 接回 workflow，在進入 plan 前，先補上 spec 裡沒有說清楚的地方。但多了這一步之後，實際做起來有什麼不同？今天就從補上 clarify 後的情況開始，再聊聊持續使用 Spec Kit 時，我碰到的其他困擾吧！
clarify 會在 plan 之前檢查既有 spec。它會逐項檢查功能範圍、資料、操作流程、例外情況與成功條件，找出規格還沒寫清楚的地方後，再透過問題讓我補上答案。它不會主動掃描 codebase，也不是提前替 plan 選擇技術或架構；它做的事情，是先讓 spec.md 本身更完整。
把答案寫回 spec 後，plan 與 tasks 至少可以依照補過細節的需求繼續往下做。AI 還是可能犯錯，spec 也還是可能和 codebase 現況對不上；但至少在進入 plan 以前，我會先看到原本 spec 裡有哪些地方還需要補充。
這也讓我開始注意到，規格寫得很長和規格寫得清楚，真的不是同一件事。整體目標很大不一定有問題，但哪些行為屬於這次範圍、例外情況怎麼處理，以及最後要看到什麼結果，至少要先在 spec 裡說明。至於一份 spec 應該切到多大，clarify 不會直接替我決定，還是得看實際範圍、風險與能不能一起驗證。
不過，clarify 接進流程後，也代表每一輪多了一個需要等待、回答與確認的階段。前面的需求細節比較清楚了，整套 workflow 卻也跟著變長。當我持續用下去後，很快就感受到：這套流程真的很花時間！
從 specify、clarify、plan 到 tasks，每一個階段都需要讓 AI 讀取資料、產生文件，再由我確認內容。這些步驟各自有用途，但串起來之後，等待時間與 Token 消耗也很明顯。
對大型需求來說，多花一些時間把問題說清楚，我覺得是值得的。可是，實際開發不會每次都剛好是一個全新的大功能。有時只是既有功能的幾個小小改動，有時做到一半才發現需求要改，或臨時多了一個需要一起處理的情況。這時候，我就會開始想：難道每次都要把整套流程重新走一遍嗎？
流程變長以外，我使用一段時間後還有另一個感受：Spec Kit 的每個階段，通常都要等我先把方向想得差不多，才比較好往下走。到了 plan，這種感覺更明顯。
Spec Kit 的 plan 會讀取 spec 與 constitution，再根據我提供的技術方向補上 research 與 implementation plan。假如連架構要不要調整、現有做法還適不適合，或有哪些技術選擇都還沒談過，我就直接執行 plan，AI 仍然會產生一套方案，但那不一定是我真正想採用的作法。
而且，隨著 AI 的能力越來越強，我也開始覺得，技術作法不一定要全部由我先想好。有些時候，我預先想到的方向未必最適合當下的規格與 codebase；甚至不少時候，先讓 AI 查看現況、提出幾種選擇，再一起比較限制與影響，最後得到的方向反而更好。
這時候，我就會先岔出 Spec Kit 的 workflow，用一般對話和 AI 討論一輪。等技術方向大致確定後，再把討論結果帶回 plan。回頭看整套流程，我發現不只 plan 是這樣。以我當時的用法來說，通常要等我先把方向想得差不多後，這些 commands 才比較容易把內容整理成下一個階段需要的 artifacts。這樣一樣可以完成工作，只是每次都要在一般對話與 Spec Kit workflow 之間來回切換，整套流程也跟著拉得更長。
plan 前的技術討論： 2025 年 10 月，也有使用者在 Spec Kit Issue #806 提到，希望 workflow 裡能有一個可以反覆討論架構與技術需求的階段。這和我當時先岔出去和 AI 討論，再回到 plan 的情況很接近。
plan 前的討論還能先在 workflow 外完成，再把結果帶回來。可是，實作已經開始後才遇到需求變動，前面產生的 spec、plan 與 tasks 要怎麼一起更新，就不是補一輪討論而已了。
既然 SDD 是規格先行，需求變了，當然應該先回去修改 spec，再讓後面的 plan 與 tasks 跟著更新。
可是，改完 spec 之後要怎麼繼續，反而成了新的困擾。當時我在 Spec Kit 的 workflow 裡找不到一套可以直接照著走的作法，把同一次修改同步到 spec、plan 與 tasks。如果只是用一般 prompt 請 AI 補規格，只要少說了其中一份文件也要跟著調整，artifacts 就可能從這裡開始對不上。放到團隊裡，每個人補規格的方式又不一定相同，更難確認相關內容是不是都有一起更新。
我也試過修改 spec 後，乾脆重新執行 plan 與 tasks。可是，當時重新執行 plan 時，既有的 plan.md 會先被新的 template 覆蓋，再根據 spec 重新產生內容。這不是把變更補進原本的 plan，而是整份重新建立；原本已經確認過的技術決策可能跟著改變，後面的 tasks 也可能和之前不一樣。
plan 為什麼會被覆蓋？ 還記得【Day - 3】目錄圖中的
.specify/scripts/嗎？當時 plan command 會用到的setup-plan.sh，就是裡面的一支腳本，負責準備這個階段需要的檔案，其中一步就是把 plan template 複製到plan.md。
規格更新的相關討論： Spec Kit Issue #1059 也有人遇到更新 spec 後重新執行 plan，既有
plan.md被 template 覆蓋的問題。我當時在 Issue 回覆裡提出一個 workaround：如果plan.md已經存在，就改用-SkipTemplate，避免再次複製 template。不過，LLM 偶爾還是沒有照著做，所以這個作法並不完全穩定。同一時期，Issue #520 也有人提議新增 change request command，專門處理 spec、plan 與 tasks 的同步更新；不過，這個 command 當時還停留在提案階段。
規格在實作途中改變，已經讓我花了不少時間處理。等 Spec Kit 用得更久、完成的需求越來越多後，我又遇到另一個問題：這些做完的規格，接下來要怎麼整理？
implement 完成後，spec.md、plan.md 與 tasks.md 都還是會留在 specs/。這些文件可以用來回顧當時做了什麼，也能在後續調整時拿來參考；只是以我當時使用的內建 workflow 來說，流程走到 implement 就結束了，至於做完的規格接下來要怎麼整理，還得自己處理。
如果把後續調整當成新的 feature，再執行 specify，就會建立另一個 feature 目錄。同一個功能改了幾次後，specs/ 裡也可能留下好幾份前後相關的 spec。當時能做的，大概就是自己搭配 AI 持續維護。一個人使用時還好，至少我知道自己前面改過什麼；只是時間久了之後，連我自己的 specs/ 裡也累積了越來越多的文件。
例如，第一次建立登入與驗證功能時，可能會留下一個 NNN-add-auth；後來替同一套功能加入 MFA，又會建立另一個 NNN-add-mfa。這裡先省略實際編號，只看兩份規格之間的關係：
從資料夾名稱可以看出前後做過哪些變更，但如果我想知道 auth 現在完整的行為，光看其中一份 spec.md 還不夠。最初的規格可能已經被後面的變更修改，新的規格也可能只寫這次加入的 MFA，最後還是得把兩份文件找出來一起整理。
我原本期待規格可以直接告訴我系統現在怎麼運作。可是，當同一個功能的內容散在前後幾份 spec 裡，就很難只看其中一份得到完整答案。每次要確認時，都得再請 AI 幫忙把相關的 spec 找出來重新整理。如果放到團隊裡，又沒有共同的流程或規範，每個成員都用自己的一套方法維護，時間一久，規格也很容易越整理越亂。
累積規格的相關討論： 2025 年 9 月的 Spec Kit Issue #620 也有人遇到相同困擾：後續功能持續增加後，原本的 spec 可能只剩下部分內容仍然正確，同一個功能的完整行為則散在前後幾份 feature specs 裡。當時提出的問題也很直接：這些規格到底該修改原本那份、保留多份歷史紀錄，還是另外整理成一份集中管理的規格？
現在有什麼不同？ Spec Kit 後來補上了 Evolving Specs in Existing Projects 指引，把規格維護整理成 flow-forward、living spec 與 flow-back 三種方式。現在可以保留每個 feature 目錄作為歷史，也可以持續更新既有的
spec.md，再手動修改或重新產生 plan 與 tasks。我在 2025 年使用時還沒有這份指引，當時不管是中途修改，還是完成後怎麼整理，都只能自己慢慢摸索。
規格越積越多，是功能做完後才慢慢出現的問題。可是回到當時那套既有系統，下一個需求還沒開始前，就會先碰到另一個問題：AI 得先弄清楚系統現在到底怎麼運作。
以我當時使用的版本和那套內部系統來說，從需求一路產生 spec、plan 與 tasks 的流程，在 greenfield 專案裡確實比較直覺。到了 brownfield，除了說明「接下來想做什麼」，還得先讓 AI 理解現在怎麼運作、哪些架構與慣例需要沿用，以及哪些行為不能被新功能弄壞。這些資料可能散在 codebase、tests、CLAUDE.md、constitution 與過去的決策裡；一旦理解錯誤，新產生的 artifacts 就可能從錯的基礎繼續往下走。
brownfield 的相關討論： 當時也有其他使用者提出相近的問題。Issue #438 希望增加從既有 codebase 反向建立規格的能力；Issue #916 則討論既有專案的 specs 要怎麼隨後續開發保持同步。這些討論和我的使用感受很接近：到了既有系統，多了一層歷史與現況需要先弄清楚。
除了理解既有系統的困難，我也記得，當時有些需求執行久了，AI 會開始漏掉前面交代的規範。這次整理鐵人賽文章時，我才回頭想：這會不會也和 command 的運作方式，以及 auto compact 有關？
當時有些需求執行很久。我印象中 Claude Code 觸發 auto compact 後，AI 偶爾不再完整遵循前面交代的部分規範，也沒有照著 Spec Kit command 原本要求的停止與驗證方式繼續執行。
我的猜測是，auto compact 後的摘要可能沒有完整保留 command 原本展開到 session 裡的提示詞。這樣一來，不管當時執行的是哪一個 command，壓縮後的 AI 都可能只記得大概要做什麼，卻沒有保留原本每個步驟的細節與要求。
不過，前面那些沒有釐清的需求、錯誤的 research 與互相矛盾的規範，本來就可能讓實作偏離。至於 auto compact 是否讓 command 裡的指示更難延續，是我這次回頭整理時才想到的可能原因；但當時沒有留下完整的 session 紀錄，所以現在也無法確認了！
當時用了一段時間後，我已經比較知道怎麼配合 Spec Kit 完成開發，但也開始想調整其中幾個步驟。技術方向還沒確定時，能不能直接在 workflow 裡先和 AI 一起討論？規格中途改變時，修改 spec 後，plan 與 tasks 能不能跟著一起更新？功能完成後，我也希望留下來的規格可以繼續告訴我系統現在怎麼運作，而不是每次都要從好幾個 feature 目錄往回找。到了既有專案，則要先整理現況與過去留下的限制，再開始產生新的規格。
帶著這些問題，以及使用 Spec Kit 累積的經驗，我於是找上了當初在 Threads 上也看過不少討論的另一個選擇：OpenSpec。下一篇，就先來看看 OpenSpec 怎麼安排從需求到實作的流程吧！
-SkipTemplate 作法
iThome鐵人賽
看影片追技術